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Abstract 

We present a system designed for the interactive definition and visu- 
alization of fields derived from large data sets: the Demand-Driven 
Visualizer (DDV). The system allows the user to write arbitrary ex- 
pressions to define new fields, and then apply a variety of visualiza- 
tion techniques to the result. Expressions can include differential 
operators and numerous other built-in functions, all of which Me 
evaluated at specific field locations completely on demand. The 
payoff of following a demand-driven design philosophy throughout 
becomes particularly evident when working with large time-series 
d at a where the costs of eager evaluation alternatives can be pro- 
hibitive. 


1 Introduction 

hi many scientific visualization applications, the data sets tend to 
bo lame. In computational fluid dynamics iCFD). for example, data 
can be on the order of one to hundreds of gigabytes in size. CFD 
data f picaily come in the form of meshes and Melds defined in 
terms of the meshes. A mesh represents the locations of a discrete 
set of vertices in a domain and the organization of the vertices, for 
instance to form hexahedral cells. In some cases a mesh may con- 
sist of multiple, overlapping submeshes, referred to as zewe-s- A 
field has a mesh and a discrete set of nodes where quantities such as 
density and momentum are represented. The location of the nodes 
is specified by the mesh. Visualization techniques start with a field 
and produce images which highlight various features in the domain. 
Some techniques, such as basic implementations of isosurfaces or 
volume rendering, require processing every cell or node in the fie d 
in order to produce an image. Many other techniques require field 
values only from small regions within the domain. For instance, a 
visualization displaying a cutting plane passing through the domain 
may require only that the field be sampled at points on the plane; or 
perhaps one may only require data near an aircraft model surface in 
order to apply LIC techniques [16] or to define contour curves or 
glyphs. Scenarios where an application touches only a small per- 
centage of the whole data set are known as sparse traversal [:>]. 
Data that varies with time lend to magnify the impact of sparse 
traversal, since sparse access can occur in both space and time. Fur- 
thermore. the implications of sparse traversal become more signifi- 
cant with time-series data since the data sets tend to be larger than 

in steady cases. . 

An important concept in computational fluid dynamics is tnat 
of derived fields. A derived field is a field whose values are com- 
puted in terms of one or more other fields. Derived fields come 
into play in simulation applications since programs which solve for 
field values typically compute only a particular set of fundamental 
solution values from which all other quantities can be derived. A 
typical set of fundamental solution variables is density, momentum 
and energy. There are numerous derived fields that a scientist may 
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be interested in viewing. For instance. Table 1 lists the over 50 
derived fields predefined by one CFD post- processing application: 
PLOT3D [20]. Derived fields are particularly a challenge when 
working with large data sets, since loading the fundamental solu- 
tion values alone into main memory may already tax the resources 
of one’s workstation. Furthermore, even if one can afford the mem- 
ory necessary to store a derived field, much of the computation may 
be unused if the visualization does not access the whole field. 

To address the challenges presented by large data in general and 
denved fields in particular, we present a visualization system based 
on a calculator paradigm, the Demand-Driven Visualize r. Using 
[he system one can interactively specify denved fields and apply 
visualization techniques to those fields. The fields can be defined 
by arbitrary expressions or by any of the standard PLOT3D denved 
fields, yet the evaluation of derived quantities is completely demand 
dnven (also known as lazy evaluation). At the user s option, the cal- 
culator can also evaluate and store the denved value over the whole 
field (eater evaluation ). or cache lazily evaluated results at some 
instance in time ( lazy but thrifty evaluation > for better performance. 
Ai the heart of the system is the Field Encapsulation Library t FEL) 
and a collection of visualization techniques known as the VtsTech 
Librarv FEL supports the dynamic construction and composition 
of arbitrary derived fields, and evaluation by lazy or eager methods. 
DDV provides the parsing to convert user expressions to FEL fields, 
and an interface where the user can interactively choose visualiza- 
tion techniques to apply to the results. The combination of the lazily 
evaluated derived fields dnven by visualization techniques provides 
a powerful system for field analysis that is especially well suited for 
large data needs. 

The power of lazy evaluation becomes particularly apparent 
when working with large time-series data sets, where the shortcom- 
inas of eager derived field evaluation— memory consumption and 
unused calculations — are multiplied by the number of time steps 
in a simulation. Since typical simulations may have on the order of 
hundreds of time steps, these drawbacks are significant. In the DDV 
design field evaluation is completely dnven by the visualization 
techniques, both in space and in time. The system automatically 
manages a working set of time steps, doing temporal tnterpolation 
if necessary. 

In the following section we discuss some previous work related 
to the Demand-Driven Visualizer. Section 3 describes the ke> 
demand-dnven fields used by DDV. Section 4 gives an overview 
of the interpreter language and the user interface ot the system. In 
Section 5 we present results demonstrating some ol the advantages 
of the DDV design. And finally, in Section 6 we conclude with 
some final thoughts. 


2 Related Work 

Field and mesh objects in the Demand-Driven Visualizer are pro- 
vided bv a C++ class library known as the Field Encapsulation Li- 
brarv (FEL). An initial version of FEL was presented at Visualiza- 
tion '% [4|. Since then the library has been redesigned and com- 
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Table I: Derived fields predefined in PL0T3D [20]. 


pletely rewritten in order to support a much wider variety of mesh 
and field types [10]. In particular, the features essential for large 
data handling - derived fields, differential operator fields, demand- 
driven evaluation, working set management of time-series data, and 
demand-paged data from disk [5] - were not available in the origi- 
nal version of FEL. 

The calculator paradigm used in DDV is a relatively intuitive and 
easy-to-use interface for preparing data for visualization. FAST [3], 
for example, is aCFD visualization system which features a calcu- 
lator module. In FAST the user can specify arbitrary expressions, 
including predefined fields such as those in Table I. and use the 
resulting scalar and vector fields just as one would use the funda- 
mental scalar and vector fields. The FAST calculator evaluates its 
results eagerly: new fields require allocating memory and comput- 
ing the derived value over the whole field. There is little support for 
time- varying data in FAST 

An alternative paradigm for effectively specifying derivation 
functions and visualization techniques is data-flow. AVS [19], IBM 
Data Explorer [8. I], IRIS Explorer [6], SCI Run [2, 12], and vtk 
[14] are all examples of data-flow implementations. Data flow sys- 
tems in general can be classified as either push model or pull model. 
In a push model system, changes to one module cause it to push re- 
sults downstream through the flow graph. AVS, Data Explorer and 
IRIS Explorer are examples of push model systems. In a pull model 
design, a change to one module results in data requests propagating 
upstream through the flow graph, where the appropriate data are 
processed and effectively pulled downstream. Vtk is an example of 
a pull model design. In SCI Run modules can operate in either pull 
mode or push mode [12]. 

For field visualizations where only a small subset of the field 
data is required, push model data-flow suffers from the drawbacks 
of eager evaluation: modules typically operate over the whole field 
even though ultimately only a relatively small amount of data need 


be processed, and potentially a large amount of memory must be 
allocated for buffering intermediate and final results. Memory us- 
age problems can be ameliorated to a certain extent by more care- 
ful memory management techniques, or by designing modules that 
work with finer-grain units of data [18]. One solution to the waste- 
ful computation problem is to introduce filter modules near the head 
of the flow graph which extract subsets of the data. Unfortunately, 
it can be difficult in some cases to anticipate what the appropri- 
ate subset should be. For example, if the downstream module is a 
particle tracer, then it may be hard to choose the subregion for com- 
puting a derived velocity field, because one would have to know a 
priori where the particles would go. Time-series data adds another 
dimension to the problem, since it may be difficult to anticipate 
where temporally a module may need data. For instance, a streak- 
line module may require data over a range of times, including times 
intermediate to the given time steps (i.e.. where temporal interpo- 
lation is necessary). One could also imagine scenarios where dif- 
ferent modules in the same flow graph may need data at different 
temporal points in the data set. 

In contrast to push model designs, pull model designs offer the 
potential of better performance in large data, sparse traversal sce- 
narios. In a pull model system, each module can request just the 
data it needs from the one or more modules immediately upstream. 
For example. Image Vision [15] is a library for image processing 
with a pull model design, where operations can be applied to small 
tiles from much larger images. SCIRun [12] modules can request 
field values from upstream modules at individual points in space. 
Such pull model systems represent lazy evaluation embodied in a 
data-flow setting: the flow graph defines the operations to be ap- 
plied to the data, but the operations are executed only at specific 
points or within specific regions, on demand. 

Lazy evaluation techniques have also been employed in other 
visualization systems for large data. The Unsteady Flow Analy- 


sis Toolkit (UFAT) [7] is a system designed specifically for par- 
ticle tracing through large, time-series data. UFAT computes de- 
rived field values on demand, but only for the velocity field. Cox 
and Ellsworth apply a demand-driven approach to the loading of 
data into main memory [5J. Using demand-paging techniques, they 
show good performance with large CFD data sets in sparse traver- 
sal scenarios, including cases where the fundamental solution data 
for a single time step are larger than the mam memory of the target 
workstation. 


3 FEL Fields 

The Demand-Driven Visualizer builds upon five key field types in 
the Field Encapsulation Library (FEL): time-senes fields, derived 
fields, differential operator fields, paged fields, and cached fields. 
The FEL field classes are defined within a common class hierarchy, 
and all fields inherit a standard interface defined by the FEL.field 
and FEL_typed.fi eld<T> classes at the top of the hierarchy. 
The typed field class is written using C++ templates where the T 
parameter specifies the field node type, e.g., float for a scalar 
field. Each field instance also has a mesh which specifies the loca- 
tion and organization of the field node data, in FEL a field node is 
located at each vertex in the mesh. The field interface provides stan- 
dard methods tor accessing field vaiues. An application can request 
node values at the vertices of a cell (at.cell), or at an arbitrary 
physical position (at.phys.pos). FEL uses a general definition 
for cell: vertices, edges, triangles, quadrilaterals, tetrahedra. and 
nexahedra are all cells. Calls to at.cell do not require spatial 
interpolation, calls to at.phys.pos do Field visualization appli- 
cations written in terms of the standard “at" calls work with any 
field subclass. FEL field classes include FEL.core.f ield<T>, 
where the node data are stored in main memory, and other fields 
where node data may be synthesized on demand. We describe the 
five types of fields that figure most prominently in the Demand- 
Driven Visualizer design next. 


3.1 Time-Series Fields 

Large simulation data sets often come in the form of a time 
series, where each time step represents a snapshot of the field 
values in time. FEL represents time-series data via the class 
FEL_t ime.ser ies_f ield<T>. Time-series fields support the 
interface common to all FEL fields, thus one can build arbitrary 
demand-driven fields for time-varying data just as one can for 
steady data. Visualization techniques request field values using the 
same arguments as in the steady case: cells and physical positions. 
Each argument contains a time representation, which is used by 
FEL.c i.T.e.ser ies.f *eld<T> instances to select the appropri- 
ate time step data, or to select multiple time steps when temporal 
interpolation is necessary. The requirement that the time compo- 
nent of “at” call arguments be set is the only difference for the 
application programmer between using a steady or unsteady field. 

FEL_t ime.ser ies.f ield<T> instances load data for a par- 
ticular time stop on demand, using a callback function provided at 
construction time Data are managed in memory using a working 
set approach, where the time steps are replaced when necessary us- 
ing a least recently used policy. The size of the working set can be 
set by the user: thus one can trade-off memory usage for a greater 
likelihood that a desired time step will be in memory. The work- 
ing set mechanism contained in FEL_t ime.ser ies.f ield<T> 
makes it easier to design applications, such as the Demand-Driven 
Visualizer , for time series data that arc much larger than workstation 
mam memory. 


3.2 Derived Fields 

The derived field classes in FEL are all subclasses of 
FEL.derived_f ield<T>. For an application programmer, the 
construction of a derived field requires arguments specifying the 
fields to be derived from, and a mapping function to be used on de- 
mand to produce derived values. All the fields must be based on the 
same mesh. The Demand-Driven Visualizer utilizes several prede- 
fined derived field classes, such as FEL_magnitude.fi eld and 
FEL_sum_f ield, where the mapping functions are provided by 
the library. 

An important consequence of defining derived fields in terms of 
the base class FEL.typecLf ield<T>, rather than a more specific 
field type such as FEL.core.f ield<T>, is that derived fields can 
be constructed in terms of other derived fields. In general one can 
compose fields deriving from any field subclass. This also implies 
that one can build chains of derived fields to arbitrary lengths. The 
fact that one can construct new fields without needing to know the 
specific subclass of the fields being derived from makes it easier to 
build modular systems. For example, in the Demand-Driven Visual - 
izer, derived fields can be composed incrementally as the interpreter 
traverses an expression parse tree. 

The relationships between de rived fields can be described us- 
ing a directed graph. An application builds derived fields node by 
node, each newly constructed field adding a graph node and edges 
from previous nodes to the new node. The graphs are acyclic, thus 
derivation graphs are DAGs (directed acyclic graphs). The deriva- 
tion graphs can also be thought of as flow graphs. Requests to a 
particular graph node cause requests to propagate upstream through 
the flow graph in a demand-pull manner The data requests are fine- 
grain: at.cell calls require computation onlv at the nodes of a 
cell. 


3.3 Differential Operator Fields 

FEL contains field classes which compute the divergence, gradient 
or curl of an underlying field. Differential operator field values are 
computed on demand, similar to derived fields. The library provides 
classes for computing derivatives by first or second order methods’ 
Other differential operators, such as the scalar or vector Laplacian, 
can also be represented in terms of the built-in operators. Temporal 
derivatives are not yet implemented in FEL. 

As with derived fields, the field provided as a construction ar- 
gument when building a differential operator field can be any 
subclass of FEL.field. Thus, differential operator fields can 
be composed into derivation chains just as derived fields are. 
Second-order differential operator fields are unlike subclasses of 
FEL.derived.f ield<T> in that they generate additional “at" 
calls on their underlying field in order to acquire a neighborhood of 
field values surrounding a given argument. For instance, a request 
for the gradient at a vertex requires field values at the adjacent ver- 
tices m the mesh in order to compute the necessary difference val- 
ues. This expanding neighborhood of calls to fields upstream in 
the derivation graph is transparent to the end user of a differential 
operator field. 

3.4 Paged Fields 

With paged fields, the data are organized into page-sized blocks 
within files on disk. Blocks are automatically loaded into memory, 
on demand, by the paged field object. The pages are managed using 
working set techniques. The loading and management of blocks is 
transparent to the paged field user. The FEL.paged.f ield<T> 


1 Presently only first order methods are supported for unstructured 
meshes. 



Operator 

Description 

__add__ 

addition (infix +) 

_div_- 

division (infix /) 

_mul_ 

multiplication (infix *) 

__neg__ 

negation (unary -) 

__sub_ 

subtraction (infix -) 

cross 

cross product 

cur 11 

first-order vector curl 

curl2 

second-order vector curl 

divl 

first-order divergence 

div2 

second-order divergence 

doc 

dot product 

gradl 

first-order gradient 

grad2 

second-order gradient 

mag 

vector magnitude 

sqrt 

square root 


Table 2: Field math operators defined in DDV. 


class encapsulates the approach presented by Cox and Ellsworth at 
Visualization '97 [5]. 

3.5 Cached Fields 

The derived and differential operator fields in FEL follow a max- 
imally lazy strategy. No derived values are computed in advance, 
nor is any memory allocated for storing derived values. In cases 
where an application repeatedly requests values at the same loca- 
tions in a field, the maximally lazy approach may not be the best, 
since the derived values would be recomputed at each request. On 
the other hand, eager evaluation may still not be the best choice, 
particularly in sparse traversal situations. FEL provides a hybrid 
approach via a field class: FEL.cachecLf ield<T>. A cached 
field is constructed with another FEL field instance as an argument. 
Cached fields allocate the memory to store the whole field (at one 
instance in time) and mark each node with a special “unevaluated" 
value. For each "at" call, a cached field checks whether the re- 
quested node values have been evaluated already, and returns previ- 
ously computed values if available. Node values requested for the 
first time are computed as in the uncached case, and stored for fu- 
ture reuse. The time component of the at call argument is ignored, 
thus it is inappropriate to use a cached field if the the underlying 
ficid is time varying and the time specified in ail the at calls is not 
the same. 

In sparse traversal scenarios, cached fields provide amortized re- 
sponse time close to that of eager fields, without the wasteful com- 
putation drawback of eager evaluation. For demand-dnven fields 
that are expensive to evaluate, in particular differential operator 
fields, cached fields can significantly improve performance when 
one can afford the memory. 

4 Implementation 

The Demand-Driven Visualizer provides a graphical interface al- 
lowing the user to interactively define and visualize arbitrary de- 
rived fields. In this section we provide a brief overview of the in- 
terpreter language used to express such fields, and the rapid appli- 
cation development language used to build the system — Python. 

4.1 The Language 

The DDV interface includes an interpreter window where the user 
can write and evaluate field expressions (see Figure 1). The inter- 
preter in DDV is based on Python [9. 1 3 1. an interactive, interpreted 
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language. A key feature of Python is its extensible, modular de- 
sign. DDV provides an FEL module for Python which introduces 
mesh and field types into the interpreter environment. The types 
are first class, in other words, once the FEL module is imported 
one can use the mesh and field types just as one uses other built-in 
types. For instance, field types can be used in expressions, assign- 
ment statements, or passed as arguments to user-defined routines. 
Python parses expressions, using operator precedence similar that 
in the C language, building a parse tree internally. Table 2 lists the 
operators that can take field arguments in an FEL-extended Python. 
The interpreter traverses the parse tree, building FEL fields as di- 
rected by the tree. The demand-driven nature of FEL is essential 
here: the interpreter can traverse and build at interactive rates, even 
though the fields may be extremely large. 

4.2 Visualization Techniques 

Once one has defined fields within the interpreter environment, the 
next step is to apply visualization techniques. DDV utilizes a C++ 
suite of visualization techniques known as the Vistech Library [17]. 
For each visualization technique. DDV provides a Python wrapper. 
Within the interpreter environment one can construct visualization 
instances and view the graphical output. Visualization instances can 
also be constructed via a menu-driven interface, described next. 

4.3 The Graphical User interface 

The graphical user interface (GUI) of the Demand-Driven Visual- 
izer is illustrated in Figure 1. The GUI is written using the Tk in- 
ter interface provided by Python. Tkinter is a wrapper around 
Tcl/Tk [II]; like Tk, Tkinter allows system designers to spec- 
ify a graphical user interface in a windowing-system-independent 
manner. The DDV GUI gives the user choice: novice users can 
use the pull-down menus and buttons to construct and control vi- 
sualization instances, while advanced users can use the interpreter 
command line alone to control the application. Python provides a 
universal language that supports both the specification of fields for 
visualization and the command and control of the application. 

5 Results 

To demonstrate the effectiveness of the Demand-Driven Visualizer 
with large data sets, we begin by quantifying the sparse data access 
patterns typical of many visualization techniques. Next, we show 
how the DDV exploits such patterns, avoiding the drawbacks of ea- 
ger evaluation. The example derived fields and visualizations are 
computed for three CFD data sets: the space shuttle launch vehi- 
cle (SSLV), the delta wing (DW). and the F- 18 fighter (F18). The 
SSLV data set is a steady simulation and has a mesh consisting 
of 1 13 zones. The delta wing and F-I8 data sets represent time- 
varying single and multi-zone flow simulations, respectively. The 
delta wing mesh also varies with time, the F-18 mesh does not. Ta- 
ble 3 summaries the data set sizes. 

A first step towards confirming that a lazy evaluation strategy 
will be effective is to verify that many visualization techniques re- 
quire accessing or “touching" only a small percentage of the field 
values in a data set. Touching a small fraction of the data implies 
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Table 5: Construction and visualization timings (in seconds) for four derived fields, ordered by increasing expense to evaluate (times desig- 
nated - are less than 1 millisecond). In all cases the time to construct a lazy field and apply a visualization technique is much less than the 
construction time alone for an eager field. The table also shows that caching can improve the performance of a visualization based on a lazy 
field that is expensive to evaluate, but caching can hinder performance when evaluation is cheap. 
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Tabic 4: The percentages of nodes touched at least once, and more 
than once, for typical cutting plane and streamline visualizations. 
The numbers are typical of visualization algorithms with sparse 
traversal behavior. 


that a large fraction is untouched, and a large fraction untouched 
implies a large amount of unused computation in an eager evalu- 
ation design. We also measure how many field nodes are touched 
more than once by the example visualization techniques. Cases 
where many nodes are touched more than once suggest opportu- 
nities where caching could make a significant improvement, since 
more values would be reused. Table 4 summarizes the measure- 
ments. The density and divergence.of -velocity scalar 
fields were visualized using a cutting plane sampling, and the ve- 
locity field was visualized via a particle advection technique. 
The percentages show the relatively low number of nodes touched, 
in most cases less than 59F The exact statistics vary with the posi- 
tioning of the cutting plane or particle advection rake. For example, 
with the SSLV data, a plane cutting between the shuttle and fuel 
tank passes through several fine detail meshes, increasing the touch 
counts. The SSLV counts in Table 4 are for such a plane position. 
The counts for the divergences f .velocity field are for a 
plane in the same position as for the density field. Note that the 
touch counts for the divergence field are higher, since node values 
from a neighborhood surrounding the plane are required. Note too 
that the percentage of nodes touched more than once is over half the 
percentage of nodes touched at all. suggesting that caching derived 
results may improve performance. 

The consequences of choosing a demand-driven design over an 
eager-evaluation design become apparent when we consider the 
times required to compute derived field visualizations. Table 5 sum- 
marizes the performance of four example fields using eager, lazy 


and cached-lazy evaluation techniques. In order to focus on the 
performance differences due to the different types of derived fields, 
the timings are for a single visualization technique, sampling with 
a cutting plane. The measurements were taken on an SGI Onyx2 
workstation with one GByte of main memory and a 195MHz pro- 
cessor clock rate. The four derived fields include a trivial derived 
field, density, two commonly used non-trivia! derived fields de- 
fined by PLOT3D [20), and a custom defined field (pressure gradi- 
ent dotted with velocity) sometimes used for feature detection. 

To isolate the costs of eager evaluation, the timings are broken 
down into construction and visualization contributions. In the case 
of every field and data set combination (i.e. every row in the table), 
the eager construction time dominates. In many cases the differ- 
ence between the eager construction time and the visualization time 
using a lazily evaluated field is over an order of magnitude. Thus 
even in cases where the user desires multiple visualizations over the 
same derived field, the total time consumed using a lazily evaluated 
field would still be less than going the eager route. Note Luo that by 
taking the lazy evaluation approach the user also comes out ahead 
in terms of memory consumption. Eager fields require significant 
amounts of memory for storage. Furthermore, in some cases one 
may have to use yet more memory, at least temporarily, to store the 
intermediate fields used to compute a field defined in terms of other 
derived fields. In cases where the fundamental solution values alone 
consume much of the memory of one’s workstation, not having to 
store derived values may make the difference between reasonable 
performance and thrashing. 

Tabic 5 also lists the times to construct and utilize lazily eval- 
uated fields where derived values are cached for reuse. The num- 
bers show improvements when working with relatively expensive 
derived fields, but a downgrade in performance when caching is 
coupled with fields that are cheaper to evaluate. To decide whether 
caching will be effective, one has to consider not only the field eval- 
uation cost, but also the field access patterns of the visualization 
technique, and the amount of memory available for caching. We 
are continuing to study these trade-offs as we further optimize the 
the performance of the field classes and visualization techniques. 

6 Conclusion 

We have presented the Demand-Driven Visualize r % a system de- 
signed from the start to address large data visualization needs 
through demand-driven evaluation techniques. The system features 
a general, flexible interpreter where one can define arbitrary de- 
rived fields, yet still enjoy the advantages of lazy evaluation. Lazy 
































evaluation excels in sparse traversal scenarios, i.e., in cases where 
an application touches a relatively small subset of the data. Many 
visualization techniques, such as particle tracing or visualizations 
defined on a surface within the domain, exhibit sparse traversal be- 
havior. The issues addressed by a demand-driven design are es- 
pecially pronounced with time-series data: eager evaluation with 
unsteady data can lead to a great deal of unused computation and 
memory consumption that can overwhelm most workstations. 

It is important to note that key to the effectiveness of DDV are 
several demand-driven design features working in concert. Using a 
lazy evaluation model in some places and eager in others can lead to 
a counterproductive design. For example, demand-paging has been 
shown previously [5] to be an effective approach to large data visu- 
alization. but demand-paging coupled with eager derived field eval- 
uation would be self defeating. Eager derived fields would force ev- 
ery page to be read in, and the memory consumption of the derived 
field would often outweigh the savings gained with paging. Since 
derived fields are often desired in simulation data visualization, it is 
important to take an approach that preserves and extends the ben- 
efits gained by other large data visualization techniques, both for 
steady and unsteady flow 
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